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ABSTRACT  /}-/  _ _ 

As  software  becomes  more  complex,  more  sophisticated  development  and  maintenance 
methods  are  needed  to  ensure  software  quality.  Computer  Aided  Prototyping  achieves  this  via 
quickly  built  and  iteratively  updated  prototypes  of  the  intended  system.  This  process  requires 
automated  support  for  keeping  track  of  many  independent  changes  and  for  exploring  different 
combinations  of  alternative  changes  and  refinements.  This  paper  formalizes  the  update/change 
merging  process  and  extends  the  idea  to  multiple  changes  to  the  same  base  prototype.  Applications 
of  this  technology  include:  automatic  updating  of  different  versions  of  existing  software  with 
changes  made  to  the  baseline  version  of  the  system;  integrating  changes  made  by  different  design 
teams  during  development;  and  checking  consistency  after  integration  of  seemingly  disjoint 
changes  to  the  same  software  system. 

KEYWORDS 

SOFTWARE,  AUTOMATION,  COMPUTER  AIDED  PROTOTYPING,  MAINTENANCE, 
FORMAL  MODELS,  SOFTWARE  ENGINEERING,  SOFTWARE  MERGING,  CHANGE 
INTEGRATION,  CASE  TOOLS 

I.  INTRODUCTION 

Software  development  is  an  ever-increasing  and  complex  industry.  As  software  systems 
gain  sophistication  and  maintaining  them  becomes  more  difficult,  automated  software 
development  methods  and  the  supporting  formal  models  must  be  devised  to  increase  reliability  and 
decrease  post-development  maintenance  effort. 

Computer  Aided  Prototyping  is  one  such  method  to  reduce  maintenance  costs  by  making 
the  original  requirements  conform  more  closely  to  the  real  needs  of  the  users.  Systems  correctly 
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implementing  an  accurate  set  of  requirements  have  lower  maintenance  costs  because  there  are 
fewer  surprises  when  the  system  is  put  into  actual  use.  An  appreciable  part  of  the  maintenance 
activity  can  be  carried  out  by  changing/updating  the  prototype  rather  than  repeatedly  updating  the 
production  version  of  the  intended  system.  This  is  useful  because  the  prototype  description  can  be 
significantly  simpler  than  the  production  code  if  the  prototype  is  expressed  in  a  notation  tailored  to 
support  modifications,  and  the  software  tools  in  the  computer  aided  prototyping  environment  can 
help  carry  out  the  required  modifications  rapidly  [Lu  89].  Prototyping  a  software  system  using 
tools  decreases  development  time  and  increases  maintainability,  because  it  reduces  customer 
dissatisfaction  with  the  delivered  system  [Lu  92]. 

The  designers  construct/change  prototypes  of  the  intended  systems  quickly  to  meet  the 
customer’s  desires  during  the  requirements  analysis  phase.  The  designers  need  automated  tools 
which  will  allow  several  changes  to  a  base  version  of  a  software  prototype  to  be  automatically 
combined  as  well  as  automatically  propagated  through  multiple  alternative  versions  of  the 
prototype.  Formal  models  are  the  keys  and  foundations  for  building  such  automated  tools. 

Change  merging  is  the  process  of  automatically  combining  the  effects  of  several  changes 
to  a  software  system.  Change  merging  has  been  studied  in  the  context  of  software  maintenance  and 
conventional  methods  for  software  development.  Early  version  control  systems  such  as  SCCS 
[Si92]  and  RCS  [Ti  82]  provide  primitive  change  merging  facilities  based  on  string  editing 
operations  on  the  source  text,  without  considering  the  effects  on  program  behavior.  However 
automated  tools  must  provide  guarantees  regarding  program  behavior  to  be  trusted  by  designers. 
Semantically-based  change  merging  seeks  to  construct  a  program  whose  behavior  agrees  with  the 
changed  version  in  all  situations  where  the  behavior  of  a  changed  version  differs  from  the  behavior 
of  the  base  version.  The  behavior  of  the  constructed  program  should  agree  with  the  base  version 
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for  all  situations  where  the  behaviors  of  all  the  changed  versions  agree  with  the  behavior  of  the 
base.  The  problem  for  functional  programs  was  considered  in  [Be  86].  Semantically-based  change 
merging  based  on  program  slicing  [We  84]  and  data  flow  analysis  has  been  studied  for  imperative 
while-programs  [Re  88,  Ho  90].  A  general  theory  of  change  merging  that  can  apply  to  any  kind  of 
programming  language  is  described  in  [Be  91a],  along  with  a  high  resolution  approach  to  change 
merging  for  while-programs  based  on  specifications  and  meaning  functions  [Li  79].  An  initial 
exploration  of  change  merging  models  for  the  prototyping  language  PSDL  can  be  found  in  [Da  90]. 

Change  merging  is  an  important  aspect  of  computer-aided  prototyping  because  the 
prototyping  process  is  characterized  by  rapid  and  extensive  changes.  The  Computer  Aided 
Prototyping  System  (CAPS)  [Lu  89]  is  a  computer  aided  prototyping  environment  comprised  of  a 
software  database  system,  an  execution  support  system,  and  a  user  interface  that  helps  designers  to 
develop  prototypes.  The  software  database  system  manages  changes  to  multiple  versions  of 
prototype  designs  and  provides  an  expert  system  to  select  and  retrieve  reusable  components  from 
the  software  base.  The  design  database  provides  concurrency  control  functions  which  allow 
multiple  designers  to  update  the  pans  of  the  prototype  without  risk  of  unintentional  interference. 
In  the  interests  of  minimizing  delay,  the  design  database  will  not  lock  out  access  to  any  pan  of  the 
design,  even  while  the  design  is  being  updated.  Instead,  the  system  will  allow  the  previous  version 
of  the  component  to  be  examined  and  updated.  Such  a  parallel  update  will  split  off  a  new  branch 
or  variation  in  the  version  history  [Lu  90].  The  system  will  provide  a  warning  that  a  new  version 
is  currently  in  preparation  and  information  about  the  reason  the  component  is  being  modified  (i.e. 
some  particular  new  or  modified  requirement)  on  request.  The  methods  proposed  in  this  paper 
provide  automated  support  for  combining  both  branches  of  a  split  resulting  from  parallel  updates 
to  produce  a  version  that  incorporates  the  effects  of  both  of  the  updates. 
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Our  goal  is  to  develop  a  tool  for  the  CAPS  system  which  will  support  automatic  merging 
of  different  versions  of  a  prototype.  We  have  developed  a  model  which  shows  that  it  is  possible  to 
correctly  perform  a  merge  operation  in  most  cases  [Da  90].  This  paper  formalizes  the  change 
process  for  the  Prototyping  System  Design  Language  (PSDL),  a  design  based  language  written 
specifically  for  CAPS,  and  uses  this  formalization  to  strengthen  our  merging  model. 

II.  PROTOTYPING  IN  CAPS 

Computer  aided  prototyping  allows  the  user  to  get  a  better  handle  on  his/her  requirements 
early  in  the  conceptual  design  phase  of  development  and  use  automated  tools  to  rapidly  create  “a 
concrete  executable  model  of  selected  aspects  of  a  proposed  system”  [Lu  89],  to  allow  the  user  to 
view  the  model,  and  to  make  comments  early.  The  prototype  is  then  rapidly  reworked  and  re¬ 
demonstrated  to  the  user  over  several  iterations  until  the  designer  and  the  user  have  a  precise  view 
of  what  the  system  should  do.  This  process  produces  a  validated  set  of  requirements  which  become 
the  basis  for  implementing  the  final  product  [Lu  89].  The  prototype  can  also  become  part  of  the 
final  product.  In  some  prototyping  methodologies,  the  prototype  is  an  executable  shell  of  the  final 
system,  containing  only  a  subset  of  the  system's  ultimate  functionality.  After  the  prototype  is 
approved  by  the  customer,  the  holes  are  filled  in  and  the  system  is  delivered.  In  this  approach  to 
computer  aided  prototyping,  software  systems  can  be  delivered  incrementally  as  parts  of  the 
system  become  fully  operational  [Lu  89]. 

CAPS,  a  computer-aided  software  development  environment,  supports  prototyping  of 
embedded  hard  real-time  systems  [Lu  89].  CAPS  reduces  the  effort  of  the  prototype  designer  by 
providing  an  integrated  set  of  tools  that  help  design,  translate  and  execute  the  prototypes,  along 
with  a  language  in  which  to  design  and  program  the  prototypes. 
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The  Prototype  System  Description  Language  (PSDL)  is  the  prototyping  language 
associated  with  CAPS  [Lu  88].  It  was  created  to  provide  the  designer  with  a  simple  way  to 
abstractly  specify  software  systems.  A  PSDL  program  is  a  set  of  PSDL  operators  and  data  types, 
containing  zero  or  more  of  each.  PSDL  operators  and  types  consist  of  a  specification  and  an 
implementation.  The  specification  defines  the  external  interfaces  of  each  operator  through  a  series 
of  interface  declarations,  provides  timing  constraints,  and  describes  the  functionality  of  the 
operator  through  the  use  of  formal  and  informal  descriptions.  The  implementation  can  either  be  in 
PSDL  or  Ada.  PSDL  implementations  are  data  flow  diagrams  augmented  with  a  set  of  data  stream 
definitions  and  a  set  of  control  and  timing  constraints. 

m.  CHANGING  PROTOTYPES 

A  current  focus  of  CAPS  is  formalization  of  the  change  process.  In  order  to  discuss  the 
merging  of  changes  made  to  a  prototype,  we  must  first  provide  a  mathematical  model  of  the  change 
process. 

PSDL  prototypes  can  be  considered  iterative  versions  of  a  software  system.  If  S  is  the 
intended  final  version  of  the  software  system,  then  each  successive  iteration  of  the  prototype  can 
be  viewed  as  an  element  of  a  sequence  S\  where  lim  Si  =  S.  Each  prototype  Sj  is  modelled  as  a 

i  ->  oo  1 

graph  G|  =  (V^,  Ev  Cj),  where: 

A.  V|  is  a  set  of  vertices.  Each  vertex  can  be  an  atomic  operator  or  a  composite  operator 
modelled  as  another  graph. 

B.  Ei  is  a  set  of  data  streams.  Each  edge  is  labelled  with  the  associated  variable  name. 
There  can  be  more  than  one  edge  between  two  vertices.  There  can  also  be  edges  from  an 
operator  to  itself,  representing  state  variable  data  streams. 

C.  Cj  is  a  set  of  timing  and  control  constraints  imposed  on  the  operators  in  version  i  of 
the  prototype. 
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The  prototype  designer  repeatedly  demonstrates  versions  of  the  prototype  to  users,  and 
designs  the  next  version  based  on  user  comments.  The  change  from  the  graph  representing  the  ith 
version  of  the  prototype  to  the  graph  representing  the  (i+l)st  version  can  be  described  in  terms  of 
graph  operations  by  the  following  equations: 

Sj  + 1  =  (Vj  + 1,  E{  + 1,  Cj  +  j)  =  Sj  +  A  Si 

ASj  =  (VAy  VRv  EAV  ERV  CAV  CRfi  where: 

Vj  +  i  -  V\  =  VA-t:  The  set  of  vertices  to  be  added  to  Sj. 

Vj- Vi+1  =  V/?j  :  The  set  of  vertices  to  be  removed  from  Sj. 

E\  +  i  -  E[  =  EA  {.  The  set  of  edges  to  be  added  to  Sj. 

E\  -  E\  +  i  =  ERt:  The  set  of  edges  to  be  removed  from  Sj. 

Cj  +  1  -  Cj  =  CA{.  The  set  of  timing  and  control  constraints  to  be  added  to  Sj. 

Cj-Cj  +  1  =  Cflj  :  The  set  of  timing  and  control  constraints  to  be  removed  from  Sj. 
The  +  operation  above  is  defined  as  follows: 

Vi  + !  =  V.  u  VA-X  -  VR-l 

E[  + 1  =  jBj  u  EA  j  —  £/fj 

Cl  +  i  =  Cj  uCAj-C/?j 

The  following  figures  show  an  example  of  a  change  made  to  a  composite  operator  in  PSDL. 
Figure  1  contains  a  graph  representation  for  a  composite  operator  Opl  consisting  of  4  vertices  and 
6  data  streams.  Figure  2  shows  a  change  to  be  applied  to  Opl  to  produce  Op2.  Figure  3  shows  a 
graph  representation  of  Op2,  the  result  of  applying  the  change  to  Opl. 
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opi^Vj,  Ej,  rj.Cj) 

Vi  -  {A,  B,  C,  D} 

Et  =  {(XI:  EXT->A),  (X2:  A->B),  (X3:  A->C),  (X4:  B->D),  (X5:  C->D), 
(X6:  D->EXT)} 

C  i  =  {max_exec_time(B,  100ms)} 
pigUre  j  Example  of  a  composite  operator  in  PSDL 

AAOpl  =  {V7?A,  VAa,  EAa,  ERa,  TAa,  TRa,  CAa,  CRa} 

VAa  =  {E} 

VRa  =  {C} 

EAa  =  {(X3:  A->E),  (X7:  E->D)} 

ERa  =  {(X3:  A->C),  (X5:  C->D)} 

CAa  =  (latency(X7,  E,  D,  50ms)} 

c*A  =  0 

p{gure  2.  Example  of  a  change  made  to  Opl. 
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Op2  =  (V2,  E2,  T2,  C2] 

V2=  VjUVAa-VRa=  {a,  B,  C,  D}  U  {E}  -  {C}  ={A,B,D,E} 

E2=Ej  u  eaa-era  = 

{(XI:  EXT->A),  (X2:  A->B),  (X3:  A->C),  (X4:  B->D),  (XS:  C->D),  (X6:  D->EXT)}  U 
{(X3:  A->E),  (X7:  E->D)}  -  {(X3:  A->C),  (X5:  C->D)}  = 

{(XI:  EXT->A),  (X2:  A->B),  (X3:  A->E),  (X4:  B->D),  (X7:  E->D),  (X6:  D->EXT)} 

C2  =  {max_exec_time(B,  100ms),  latency(X7,  E,  D,  50ms)} 

Figure  3.  Example  of  the  changed  operator  Op2. 

IV.  MERGING  PSDL  PROTOTYPES 

Merging  different  versions  of  a  program  is  useful  in  performing  automatic  maintenance  of 
software  systems.  In  prototyping,  it  is  common  for  different  versions  to  evolve  from  the  base 
system.  If  the  system  designer  discovers  a  fault  in  the  base  version  of  the  system,  it  would  be 
desirable  to  have  the  capability  to  automatically  apply  that  change  to  all  of  the  versions  currently 
in  use.  In  order  to  do  this,  the  merging  process  must  be  able  to  apply  the  change  to  the  common 
parts  of  each  version  without  a  Tecting  the  peculiar  functionality  in  each  one. 

In  [Be  90],  a  definition  of  merging  two  compatible  extensions  of  a  semantic  function  was 
given  as  follows: 
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If  the  functionality  of  the  software  systems  are  represented  using  sets,  then  the 

result  of  merging  two  extensions,  A  &  C  of  a  base  version  B  is  defined  as: 

M  =  A[B]C  =  (A  -  B)  U  (A  n  C)  U  (C  -  B) 

In  this  definition,  the  union,  intersection  and  difference  operations  are  defined  as  normal 
operations  on  sets.  The  difference  operation,  (A  -  B)  for  example,  yields  the  functionality  present 
in  the  extension,  but  not  inherited  from  the  base  version.  The  intersection  operation  yields  the 
functionality  preserved  from  the  base  version  in  both  extensions.  This  model  preserves  all  changes 
made  to  the  base  version,  whether  extensions  or  retractions. 

In  this  section,  we  express  our  method  for  merging  prototypes  using  the  change  model 
described  in  the  previous  section  and  the  above  definition.  All  PSDL  implementations  are  graphs, 
which  model  their  functionality.  We  have  represented  these  graphs  using  sets.  Different  variations 
of  a  prototype  are  the  result  of  different  changes  being  applied  to  a  common  base  version.  We  can 
merge  the  two  new  versions  A  and  C  together  by  applying  the  change  which  produced  A  from  B 
to  version  C,  or  applying  the  change  which  produced  C  from  B  to  version  A.  The  result  is  the  same 
in  either  case. 

Earlier,  we  defined  the  (i  +  l)st  iteration  of  a  software  prototype  as  St  +  j  =  Sj  +  ASj.  Let 
us  now  look  at  an  ith  version  which  has  been  changed  in  two  different  ways,  via  Aa  and  AR.  The 
result  of  these  two  changes  is  SA  and  SB  respectively.  Now  let  us  define  the  (i  +  l)st  iteration  as 

■^i  +  1  =  (-^a  —  ^j)  ^  (^Af^^B)  ^  — 

The  components  of  S|  + 1;  Vj  +  j,  E\  + 1  and  Cj  +  j  can  be  defined  similarly: 

I  =  vA[Vi]vB  =  (VA-V.)  V  (vAnvB)  u  (vB-v.), 

E;  +  1  =  Ea^^B  =  (£A-Ei)  U  (EAn£B^  U  (£B-Ei)  and 

Cj  + 1  =  cA[Cj]CB  =  (cA  -  c.)  u  (cA  n  cB)  o  (cB  -  c.) 
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To  demonstrate  the  concept  of  the  merging  operation,  we  provide  the  following  example: 
The  base  prototype  is  as  in  Figure  1.  Change  A  is  outlined  in  Figure  2,  with  the  result  shown  in 
Figure  3.  Change  B  is  outlined  in  Figures  4  and  5.  The  merging  operation  is  performed  in  Figure  6 
and  the  result  is  shown  in  Figure  7. 

The  affect  of  change  A  is  to  remove  the  operator  C  and  replace  it  with  operator  E. 
Accordingly,  the  associated  data  streams  must  also  be  changed.  The  new  data  stream  X7  also  has 
a  latency  associated  with  it,  so  a  new  timing  constraint  is  added.  The  sets,  Va,  E\  and  CA 
correspond  directly  to  V j,  E^  and  C 2  shown  in  Fig.  3. 


ABOpl  -  {VRB,  VAb,  EAb,  ERb,  CAb,  CJ?b} 

VAb  =  {F} 

VRb  =  {B} 

EAb  =  {(X2  A->F),  (X8  F->D)} 

ERb  =  {(X2  A->B),  (X4  B->D)} 

CAb  =  {max  exec_time(F^Oms)} 

CRb  =  {} 

Figure  4.  Change  B  applied  to  Opl. 
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0PB  =  {Vb,£b,7’b,Cb} 

VB=  VjUV>4b-V/?b  =  { A,  B,  C,  D}  U  {F}  -  {B}  ={A,C,D,F} 

Eb  =  Ex  U  EAb  -  ERb  =  {(XI  EXT->A),  (X2  A->B),  (X3  A->C),  (X4  B->D),  (X5  C->D), 

(X6  D->EXT)}  U  {(X2  A->F),  (X8  F->D)}  -  {(X2  A->B),  (X6  B->D)}  = 

{(XI  EXT->A),  (X2  A->F),  (X3  A->C),  (X8  F->D),  (X5  C->D),  (X6  D->EXT)} 

Cg  =  LJ  CAb  —  CRb  =  {max_exec_tirne(F,50ms),  latency (X 7,  E,  D,  50ms)} 

Figure  5.  Results  of  applying  change  B  to  Opl. 

The  affect  of  change  B  is  to  remove  the  operator  B  and  replace  it  with  operator  F.  The  data 
streams  associated  with  these  two  operators  also  have  to  be  changed  now.  A  new  timing  constraint 
is  also  added  associated  with  operator  F. 

The  merge  operation  outlined  in  Figure  6  involves  determining  the  real  affect  of  changes 
made  to  the  base,  and  any  conflict  that  may  arise  due  to  similar  changes  between  the  two  variations. 

This  is  a  simple  example  illustrating  the  merging  of  two  changed  prototypes  which  do  not 
conflict  with  one  another.  In  some  cases,  two  changes  to  a  prototype  can  conflict  with  one  another, 
and  the  result  of  their  merging  can  be  an  inconsistent  program.  In  such  cases,  the  engineer  must 
resolve  the  conflict  off-line.  The  following  section  describes  some  possible  conflicts  and  possible 
methods  for  resolving  those  conflicts. 


ll 


Op2  =  0pA[0pl]0pB  =  ( OpA  —  Opl)  (Op A  r\  OpB)  ( OpB  —  Opl)  = 

y2  =  VA[V!]VB  =  (vA  -  Vj)  u  ( vA  n  vB)  u  (vB  -  vt) . 

£2=^a[Ei]£B=  (£A-£i)  U  (EAn£B)  U  and 

c2  =  Ca[Ci]Cb  =  (ca  —  C^)  ^  (CAnCB)  (CB~  Cj) 


igure  7.  Result  of  the  merge  operation. 


V.  Conflict  Resolution 

There  are  a  number  of  possible  conflicts  which  can  arise  during  the  performance  of  the 
merging  operation.  Conflicts  arise  when  different  changes  applied  to  the  prototype  affect  the  same 
portion  of  the  prototype  in  different  ways.  Some  examples  of  conflicts  are  as  follows: 

1.  If  one  change  adds  an  output  edge  to  a  vertex  A,  while  another  change  removes  vertex 
A  from  the  prototype.  In  this  case,  automatic  resolution  of  the  conflict  is  not  yet  possible,  so  the 
system  would  have  to  notify  the  designer  that  a  conflict  has  occurred  and  give  him/her  the 
opportunity  to  resolve  it. 

2.  If  the  two  changes  assigned  different  timing  constraint  values  to  the  same  operator,  i.e., 
(max_exec_time,  F,  50ms)  and  (max_exec_time,  F,  40ms).  In  this  case,  the  conflict  can  be  handled 
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automatically,  since  any  operator  which  executes  in  under  40ms  would  certainly  execute  in  under 
50ms.  In  situations  where  different  maximum  execution  times  have  been  assigned,  the  minimum 
value  can  always  be  chosen.  This  is  also  true  of  two  different  values  for  latency,  maximum 
response  time  and  finish  within  timing  constraints.  The  minimum  calling  period  timing  constraint 
would  have  to  be  merged  using  the  maximum  of  the  different  values.  Different  period  values  for 
the  same  operator  in  different  changes  would  result  in  a  conflict  which  would  have  to  be  resolved 
by  the  designer.  Different  control  constraints  for  the  same  part  of  the  prototype  in  different  changes 
can  also  result  in  a  conflict.  Some  of  these  conflicts  can  be  resolved  automatically.  Current  work 
is  addressing  methods  for  automatic  resolution  of  conflicts. 

VI.  Conclusions 

Tool  support  for  manipulating  and  combining  specifications  is  especially  important  for 
computer  aided  prototyping.  We  are  currently  implementing  the  method  presented  here  to  evaluate 
its  effectiveness  in  practical  contexts.  We  are  also  conducting  theoretical  studies  to  evaluate  its 
limitations  and  to  discover  improvements.  The  method  described  here  works  correctly  whenever 
the  functions  computed  by  the  operators  are  one  to  one.  As  has  been  pointed  out  in  [Be  90],  a  global 
analysis  of  the  system  may  be  necessary  to  ensure  that  the  functions  computed  by  the  operators  do 
not  interfere  in  the  general  case.  For  a  more  detailed  discussion  of  the  reasons  for  this,  see  [Be  90]. 
Related  work  on  configuration  management  and  version  control  is  also  being  performed  [Ba  92]. 
Some  issues  to  be  considered  in  future  work  are  treatment  of  data  types  and  component 
specifications,  and  the  detection/diagnosis  of  semantic  interference  between  modifications. 
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